1. Field of the Invention
This invention relates to a computer architecture, in particular, to an architecture that coordinates the use of system resources for different modules such as virtual machines.
2. Background Art
The advantages of virtual machine technology have become widely recognized. Among these advantages is the ability to run substantially platform-independent applications and to run even multiple operating systems simultaneously. An example of the former advantage is Java: Java “applets” can run within different browsers, for example, as long as they have loaded the Java virtual machine. An example of the latter advantage are several of the products of VMware, Inc., of Palo Alto, Calif., which allow several different operating systems (or even different copies of the same operating system) to run at the same time on an x86 hardware platform.
As is well known in the field of computer science, a virtual machine (VM) is a software abstraction—a “virtualization”—of an actual physical computer system. As such, each VM will typically include a virtual CPU, a virtual mass storage disk, a virtual system memory, a virtual operating system (which may simply be a copy of a conventional operating system), and various virtual devices such as a network connector, in which case the virtual operating system will include corresponding drivers. All of the components of the VM may be implemented in software using known techniques to emulate the corresponding components of an actual computer.
If the VM is properly designed, then it will not be apparent to the user that any applications running within the VM are running indirectly, that is, via the virtual operating system and virtual processor. Applications running within the VM will act just as if they would if run on a “real” computer. Executable files will be accessed by the virtual operating system from the virtual disk or virtual memory, which will be simply portions of the actual physical disk or memory allocated to that VM. Once an application is installed within the VM, the VOS retrieves files from the virtual disk just as if they had been pre-stored as the result of a conventional installation of the application. The design and operation of virtual machines is well known in the field of computer science.
Some interface is usually required between a VM and some underlying host operating system and hardware (in particular, the CPU), which are responsible for actually executing VM-issued instructions and transferring data to and from the actual memory and storage devices. A common term for this interface is a “virtual machine monitor” (VMM). A VMM is usually a thin piece of software that runs directly on top of a host, or directly on the hardware, and virtualizes all, or at least some of, the resources of the machine. The interface exported to the VM is then the same as the hardware interface of the machine, or at least of some machine, so that the virtual OS cannot determine the presence of the VMM. The VMM also usually tracks and either forwards (to some form of operating system) or itself schedules and handles all requests by its VM for machine resources, as well as various faults and interrupts.
In some conventional systems, the VMM runs directly on the underlying hardware, and will thus act as the “host” operating system for its associated VM. In other prior art systems, the host operating system is interposed as a software layer between the VMM and the hardware. The implementation and general features of a VMM are known in the art.
One difficulty inherent in the nature of virtualization is that it complicates the need for management and governing of CPU, memory, and I/O resources. Not only are the VM and the VMM in themselves software components that require disk space and CPU time, but each VM acts as a “computer” in its own right, and thus duplicates the demand for resources made by the “host” system in which it is loaded. Prior art systems generally rely on the host operating system to schedule a VM on a CPU, to manage the system memory, and to provide fair sharing of network and disk resources. The problem is that existing host platforms on which virtualized systems are loaded have CPU schedulers that are often inadequate in that they don't cope well with virtual machines using large amounts of physical memory and do not even attempt to provide fair sharing of network and disk resources. This problem is of course only compounded in multi-processor systems.
One of the biggest challenges facing developers of virtualization technology is that of speed or, more precisely, lack of speed. Consider, for example, the operation of accessing the disk. In most prior art systems, if the VM issues a request for access to the virtual disk, then this request must be intercepted by the VMM and mapped to the address space of the physical disk. The VMM must then forward the request to the actual operating system that handles physical disk requests. The operating system must then schedule and carry out the request, and the data must be passed back via the VMM and on to the requesting VM.
In most cases, disk access times are acceptable, and for most applications not even noticeable to the user. The problem of delay becomes more acute, however, when the VM wants to access a resource via a network. Especially in the context of high-speed, broadband network connections, every delay translates directly into a reduction in performance. In order for a VM to transmit or receive a network packet, for example, prior art systems require switches between the VMM and the COS. This results in the VM experiencing significantly higher latency and lower throughput than the same OS running on a native machine. A similar process is gone through on each disk I/O.
Yet another concern of those who design virtualized systems is that each VM (and its related VMM or portion of a VMM) should preferably be as isolated as possible from the others. This reduces the number of possible points of failure of the system as a whole—failure of one VM should not make impossible the proper operation of the others, or of the non-virtualized components of the system.
What is needed is therefore a system architecture that allows the use of one or more VM and that efficiently manages the system resources. The system should be highly fault-tolerant, with as complete isolation of VM's as possible. The speed of the VMs' should be increased compared with the prior art, and should preferably be as close to the native performance of the underlying system as possible, even for network and disk I/O operations. This invention provides such an architecture.